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

From ArchWiki
Jump to: navigation, search
(My addition about "PAM with 'virtual users'")
(4 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
 +
== 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 ?
 +
 +
----
 +
 
What is the advantage of using the xinitd approach over adding vsftpd to the Daemon list?
 
What is the advantage of using the xinitd approach over adding vsftpd to the Daemon list?
  
Line 6: Line 14:
 
What is xinitd?
 
What is xinitd?
  
 +
^ xinitd is a typo. xinetd is the real deal.
  
 
----
 
----
Line 37: Line 46:
  
 
-- KimTjik
 
-- 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.
 +
 +
[[User:Neburski|Neburski]] ([[User talk:Neburski|talk]]) 19:05, 7 December 2013 (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?
 +
 +
--[[User:IncredibleLaser|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.
 +
 +
--[[User:Jstitch|Jstitch]] 17:35, 1 June 2011 (EDT)

Revision as of 20:42, 11 February 2014

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 ?


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.


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)

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)