Difference between revisions of "Talk:Very Secure FTP Daemon"

From ArchWiki
Jump to navigation Jump to search
Line 102: Line 102:
  
 
: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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:48, 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. --[[User:Indigo|Indigo]] ([[User talk: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 INPUT -m state --state NEW -m 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]] one should use a different commmand alltogether.

Revision as of 10:05, 12 December 2018

Deprecated pam_userdb.so

pam no longer provides pam_userdb.so (as of 1.1.8-3). The part concerning virtual user no longer works. What is the recommended workaround ?


I've added a new section to the wiki. A simple option is to use pam_pwdfile.so. Another improvement is how passwords are generated and stored. -- KimTjik (talk) 14:06, 27 February 2014 (UTC)


What is the advantage of using the xinitd approach over adding vsftpd to the Daemon list?

And also, # pacman -S xinitd xinitd: not found in sync db

What is xinitd?

^ xinitd is a typo. xinetd is the real deal.

I've updated this section. As briefly explained xinetd provides enhanced monitoring and controlling capabilities. It can handle a lot of connections, makes extensive logs. I added however a, maybe, subjective opinion that it's not necessary for a basic vsftpd configuration. It's frequently used though in production environments. I believe though that most users here choose vsftpd for its simplicity and performance. -- KimTjik (talk) 22:09, 28 February 2014 (UTC)


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.

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)

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)

Expand troubleshooting: vsftpd: Error 500 with kernel 4.18+ section

In my case I had to apply the `seccomp_sandbox=NO` fix even though I was getting `421 Service not available, remote server has closed connection` error while I was `ls`'ing or `dir`'ing. It should be expanded or maybe an extra section in troubleshooting? I can take care of this if I get a green light on it. -- Soocki (talk) 20:48, 10 December 2018 (UTC)

Please do and also add FS#50309 - it mentions your 421 error. So, I guess they are indeed linked. --Indigo (talk) 23:33, 10 December 2018 (UTC)

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 INPUT -m state --state NEW -m 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 one should use a different commmand alltogether.