I see currently no real-world secure method for users to work with web developers (SOLVED)

I

IT_Architect

Verified User
Joined
Feb 27, 2006
Messages
1,088
The Problem - Secure access for users and their contracted vendors to maintain their web sites. I brought this up in 2018 when I mentioned that people work from anywhere on anyone's wireless connections. There was not a viable solution then nor do I see one now.

- ftp - Everything is in the clear, including credentials.
- ftps - ftps is not even headed in the right direction. ProFTPd's implementation of ftps is Explicit, which is the current standard, but the client decides what if anything gets encrypted. It does not implement Implicit, the previous and more secure standard. You might as well close port 21.
- sftp - Using sshd doesn't work because it works at the user level, which means that for anyone to work on a user's web site, the user needs to give them their credentials. It also enables shell access to the user and his vendors.
- ProFTPd's mod_sftp has been an almost impossible solution for about ever as is evident from these forums, and well before my posts in 2018 when nobody could help me find a way to make it work on FreeBSD, and today if you do a standard install with CENTOS's heir apparent, AlmaLinux 8.4, and follow the implementation instructions, it will not result in a functional sftp. When Googling, people have a lot of issues implementing mod_sftp, with the vast majority remaining unresolved. Something like that is a not a valid solution.

With people working more today from everywhere, there is nothing more basic than this. Does anyone have a solution for this or is everyone just faking it?
 
Maintain Website need explanation?

Can't help but "website" is a to large possible "word"

APP , CMS system whatever.

So Userrights are normally handled in such APPS , CMS systems and not in ftp rights, so uploading and such you need to take care in the code from those Websites itself.

Normally Usergroups and rights... for Projects

Oyes edit ofcourse encrypted
 
Last edited:
I determined what is wrong with DA's install this morning and will post back when I get back.
 
IT_Architect said:
- ProFTPd's mod_sftp has been an almost impossible solution for about ever as is evident from these forums, and well before my posts in 2018 when nobody could help me find a way to make it work on FreeBSD, and today if you do a standard install with CENTOS's heir apparent, AlmaLinux 8.4, and follow the implementation instructions, it will not result in a functional sftp. When Googling, people have a lot of issues implementing mod_sftp, with the vast majority remaining unresolved. Something like that is a not a valid solution.
Click to expand...
Proftpd's mod_sftp can be made to work with virtual FTP users.

Look into using ProFTPd's AuthUserFile directive and point it to /etc/proftpd.passwd - that file contains information for virtual FTP users.

Not sure how exactly DirectAdmin's ProFTPd configuration works (do they support ProFTPd?), I'm using my own compiled ProFTPd with a custom config that uses AuthUserFile and /etc/proftpd.passwd and I haven't gotten any complaints.

So bottom line, not sure how easy it would be for you to implement, but it's definitely possible.
 
sparek said:
(do they support ProFTPd?),
Click to expand...
They always did. It was the default before pure-ftpd became the default. It's still present, you can change to ProFTPD. The /etc/proftpd.passwd is still used.
But it seems IT_Architect discovered a flaw in DA's install or the way they use it so lets wait and see what he found.
 
IT_Architect said:
help me find a way to make it work on FreeBSD
Click to expand...
Yeah I found so much wrong with the DA FreeBSD installer I had to tweak the config file in my install script.
in
For FreeBSD /usr/local/etc/proftp.sftp.conf
linux /etc/proftp.sftp.conf
Try something like
Code: 
<IfModule mod_sftp.c>
<VirtualHost 0.0.0.0>
    # The SFTP configuration
    Port "PUT your SFTP port here. Like 1212, 4040, or 5150.  Just not your ssh port"

    AuthUserFile    /etc/proftpd.passwd
    TransferLog      /var/log/proftpd/xferlog.legacy
    ExtendedLog     /var/log/proftpd/|IP|.bytes WRITE,READ userlog

    SFTPEngine on

    SFTPLog /var/log/proftpd/sftp.log
    SFTPHostKey /etc/ssh/ssh_host_rsa_key
    SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys
#Require only password authentication
    SFTPAuthMethods password

    SFTPClientMatch ".*WS_FTP.*" channelWindowSize 1GB    #WS_FTP initial window size
    SFTPClientMatch ".*ClientSftp" sftpProtocolVersion 3  #CuteFTPPro8
    SFTPClientMatch ".*WinSCP.*" sftpProtocolVersion 3    #upload/download fix for WinSCP
    SFTPClientMatch ".*SecureBlackbox.*" sftpProtocolVersion 3
    SFTPClientMatch "1.0" sftpProtocolVersion 3 channelWindowSize 1GB
    SFTPClientMatch ".*J2SSH_Maverick.*" channelWindowSize 1GB
    SFTPClientMatch ".*WeOnlyDo.*" sftpProtocolVersion 3 channelWindowSize 1GB
    SFTPClientMatch ".*EldoS.SSHBlackbox.3.*" sftpProtocolVersion 3 channelWindowSize 1GB
    SFTPClientMatch ".*IP.Works.*" channelWindowSize 1GB
</VirtualHost>
</IfModule>

Also you might what to put you server ip were 0.0.0.0 change the file for linux.
Code: 
sed -i -e "s|<VirtualHost 0.0.0.0>|<VirtualHost "your serverip"|g" /usr/local/etc/proftpd.sftp.conf
 
Last edited:
We have been using proftpd with the sftp module for a very long time and everything works fine on CentOS 6-8. Yes, the configuration in the documentation is a little inaccurate, but when you start it, an error appears in the logs and it is immediately clear what to fix, bdacus01 correctly pointed to the server ip, which must be specified, you also need to generate certificates.
 
Active8 said:
Do not agree, last update is from 29/AUG/2021 and released 1.3.8rc2 version so it is still under development and not abandoned.
Click to expand...
Not abandoned. The project isn’t maintained well. The code could be good.

I use proftpd myself. I wanted the sftp part. I had to delve into the site so I could tweak the configuration since the DA one isn’t fully up to date although it was mostly for FreeBSD.

PS. I hope you are well. So tired of all of this virus stuff. Take your Vitamin D.
 
Underlying philosophy that dictated my goals.
1. In a shared hosting environment, the most technical user for an organization takes care of setting up new E-mail users, vacation/out of the office responders, and their technical expertise doesn't extend much beyond that. There is a lot of power and security aspects native to a user account that is beyond their scope of understanding.
2. Often the user knows nothing about the character of the actual web developer. It makes no sense to share the user account credentials with them and give the unlimited access to their information nor to grant SSH capabilities to enable SFTP. The developer may have access for an extended period and the user may wish to revoke access at any time. Thus, the end game is for developers is to be virtual FTP users.
3. Not many who work on web sites are systems people. For many, WordPress is their starting point and if it isn't there, there needs to be a button to click to put it there. If there isn't, they will tell the customer they need a new web hosting company. Their education tends to be more along the lines of graphic design and making web sites in WordPress. Their design environments work with FTP, FTPS, and SFTP. It is stretch for them just to set up the site communications, let alone figure out that they need to change a port number. Thus, we want the port numbers for the least technical to be standard port numbers for FTP, FTPS, and SFTP. That means SSH needs to move off 22 to make way for SFTP with virtual users. For system admins, moving SSH to a non-standard port is something they often do as a matter of course anyway.
4. People work from anywhere and everywhere. Encryption of login credentials and data must not dependent on people's knowledge of proper procedures, protocols, and discipline to ensure the security of the user area.

I took this entire implementation area out of here and made an organized

[HOW TO] Set up your ProFTPd FTP server to support the secure protocols while disabling insecure FTP​

Other:
CSF Firewall: My expertise is with the PF firewall and I need your help understanding the CSF firewall. CSF might prove to be adequate, and I like the plug-in interface to the CSF firewall because it enables me to delegate tasks that I previous have been unable to do. However, the issue I have with it is what I see is not what I get. I can drop all of the FTP ports for IPV4 & 6, and it will continue to work just fine. No amount of re-reading and restarting will fix that. However, when I look further down, I see those ports greyed out and it seems that the firewall works with the installed services and adds them back. This is not what I expected so I either don’t understand it, or it isn’t working. What am I missing?

Thanks!
 
Last edited:
IT_Architect said:
the issue I have with it is what I see is not what I get. I can drop all of the FTP ports for IPV4 & 6, and it will continue to work just fine.
Click to expand...
That is very odd. This should not happen and I doubt this is CSF causing this.
Seems to me that the build in OS firewall is still active in some way.

If you remove the ftp ports (20, 21 and pasv ports) from UDP and TCP in csf.conf they should not be reachable from outside anymore after restarting csf/lfd.
So if they keep removed in csf.conf they should not be able to get back in, which brings me to the thought that the build in Centos firewall is somehow still active.

IT_Architect said:
However, when I look further down, I see those ports greyed out
Click to expand...
Where exactly are you looking then? Is that also in csf.conf?

Also, check /etc/sysconfig for any iptables-config, iptables6-config and/or just iptables files.
Normallyl only the iptables-config and iptables6-config should be present. And they should not have any services content.

As for the rest I can't help you, I can only try to see why FTP traffic from outside is not blocked.

You could check if a port is open in iptables like this:
iptables -nL | grep 21 | more
you can replace port 21 by the portnumber you want to investigate.
 
Richard G said:
If you remove the ftp ports (20, 21 and pasv ports) from UDP and TCP in csf.conf they should not be reachable from outside anymore after restarting csf/lfd.
So if they keep removed in csf.conf they should not be able to get back in, which brings me to the thought that the build in Centos firewall is somehow still active. Where exactly are you looking then? Is that also in csf.conf?
Click to expand...
I learned of this situation when I was going to drop 21 for a test and everything still worked. Then I decided to remove ALL FTP ports, and everything still worked. Then I checked the csf.conf, and it read the same as with the plugin, which you might say would be expected but remember I haven't worked in Linux in well over a decade and know nothing about CSF or what method the plugin uses to effect the maintenance of the csf.conf. I suspect what you are saying about the firewalld to be true, and it had been active. It is in theory NOT active and if I issue the command firewall-cmd --state it returns: not running, which makes sense because I issued commands earlier
systemctl stop firewalld
systemctl disable firewalld
systemctl status firewalld - which returns
Loaded: masked (Reason: Unit firewalld.service is masked.)
Active: inactive (dead)

What I was referring to with port numbers furthur down that I cannot change in the plugin in the area that with: "The following are comma separated lists used if LF_SELECT is enabled," However, LF_SELECT is not enabled.
Richard G said:
Also, check /etc/sysconfig for any iptables-config, iptables6-config and/or just iptables files.
Normallyl only the iptables-config and iptables6-config should be present. And they should not have any services content.

As for the rest I can't help you, I can only try to see why FTP traffic from outside is not blocked.

You could check if a port is open in iptables like this:
iptables -nL | grep 21 | more
you can replace port 21 by the portnumber you want to investigate.
Click to expand...
The iptables-config looks like this:
# Load additional iptables modules (nat helpers) # Default: -none- # Space separated list of nat helpers (e.g. 'ip_nat_ftp ip_nat_irc'), which # are loaded after the firewall rules are applied. Options for the helpers are # stored in /etc/modprobe.conf. IPTABLES_MODULES="" # Save current firewall rules on stop. # Value: yes|no, default: no # Saves all firewall rules to /etc/sysconfig/iptables if firewall gets stopped # (e.g. on system shutdown). IPTABLES_SAVE_ON_STOP="no" # Save current firewall rules on restart. # Value: yes|no, default: no # Saves all firewall rules to /etc/sysconfig/iptables if firewall gets # restarted. IPTABLES_SAVE_ON_RESTART="no" # Save (and restore) rule and chain counter. # Value: yes|no, default: no # Save counters for rules and chains to /etc/sysconfig/iptables if # 'service iptables save' is called or on stop or restart if SAVE_ON_STOP or # SAVE_ON_RESTART is enabled. IPTABLES_SAVE_COUNTER="no" # Numeric status output # Value: yes|no, default: yes # Print IP addresses and port numbers in numeric format in the status output. IPTABLES_STATUS_NUMERIC="yes" # Verbose status output # Value: yes|no, default: yes # Print info about the number of packets and bytes plus the "input-" and # "outputdevice" in the status output. IPTABLES_STATUS_VERBOSE="no" # Status output with numbered lines # Value: yes|no, default: yes # Print a counter/number for every rule in the status output. IPTABLES_STATUS_LINENUMBERS="yes" # Reload sysctl settings on start and restart # Default: -none- # Space separated list of sysctl items which are to be reloaded on start. # List items will be matched by fgrep. #IPTABLES_SYSCTL_LOAD_LIST=".nf_conntrack .bridge-nf" # Set wait option for iptables-restore calls in seconds # Default: 600 # Set to 0 to deactivate the wait. #IPTABLES_RESTORE_WAIT=600 # Set wait interval option for iptables-restore calls in microseconds # Default: 1000000 # Set to 100000 to try to get the lock every 100000 microseconds, 10 times a # second. # Only usable with IPTABLES_RESTORE_WAIT > 0 #IPTABLES_RESTORE_WAIT_INTERVAL=1000000

iptables -nL | grep 21 | more[
# Warning: iptables-legacy tables present, use iptables-legacy to see them ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:21 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:21 DROP all -- 221.182.0.210 0.0.0.0/0 DROP all -- 221.181.185.111 0.0.0.0/0 DROP all -- 221.131.165.75 0.0.0.0/0 DROP all -- 221.181.185.151 0.0.0.0/0 DROP all -- 222.186.42.213 0.0.0.0/0 DROP all -- 221.131.165.62 0.0.0.0/0 DROP all -- 221.131.165.50 0.0.0.0/0 DROP all -- 221.131.165.72 0.0.0.0/0 DROP tcp -- 36.110.228.254 0.0.0.0/0 tcp dpt:21 LOGDROPOUT all -- 0.0.0.0/0 221.182.0.210 LOGDROPOUT all -- 0.0.0.0/0 221.181.185.111 LOGDROPOUT all -- 0.0.0.0/0 221.131.165.75 LOGDROPOUT all -- 0.0.0.0/0 221.181.185.151 LOGDROPOUT all -- 0.0.0.0/0 222.186.42.213 LOGDROPOUT all -- 0.0.0.0/0 221.131.165.62 LOGDROPOUT all -- 0.0.0.0/0 221.131.165.50 LOGDROPOUT all -- 0.0.0.0/0 221.131.165.72 LOGDROPOUT tcp -- 0.0.0.0/0 36.110.228.254 tcp dpt:21

iptables -nL | grep 19 | more
# Warning: iptables-legacy tables present, use iptables-legacy to see them DROP all -- 185.165.190.34 0.0.0.0/0 LOGDROPOUT all -- 0.0.0.0/0 185.165.190.34

Drop 990 from the list of ports, which if disabled, would make it impossible for FTPiS to connect. FTPiS still works fine.
iptables -nL | grep 990 | more
# Warning: iptables-legacy tables present, use iptables-legacy to see them

Added back 990
iptables -nL | grep 990 | more
# Warning: iptables-legacy tables present, use iptables-legacy to see them ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:990 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:990

Does Linux commonly require the services of an exorcist? LOL!
 
Last edited:
Hello.
Most likely, the ip address from which you check the port availability is added to the whitelist (csf.allow). When you install csf it adds your ip from which it is whitelisted so you don’t accidentally block yourself. Check the port availability of a different ip.
 
splby said:
Hello.
Most likely, the ip address from which you check the port availability is added to the whitelist (csf.allow). When you install csf it adds your ip from which it is whitelisted so you don’t accidentally block yourself. Check the port availability of a different ip.
Click to expand...
I didn't test from a different address, but you are correct in that my IP is in csf.allow.
EDIT: I changed the ip in csf.allow and it blocked me as expected. (I can't get locked out because with VMs you always have the console screen.)

Fabulous!
Thanks TONS!
 
Last edited:
IT_Architect said:
Drop 990 from the list of ports, which if disabled, would make it impossible for FTPiS to connect. FTPiS still works fine.
iptables -nL | grep 990 | more
Click to expand...
This one at least showed that CSF is working fine and no other firewall was messing things up.

And with splby already posting the other possibility, I'm glad to see you understand now how this could happen.

Just to be sure.... remember that also csf.ignore can cause this kind of behaviour.
 
I'm learning the nuances of Linux a little at a time. Since UNIX defined its architecture, nothing has been strange or difficult. It's higher-level than I'm used to but I can learn the nuances of its automation. This firewall issue is a perfect example. I would never have guessed it picking up my IP during install and white listed it. That's a nice touch unless you don't know it's there. I've learned Windows Server and that's a lot higher level than Linux. My only concern is that it can take the heat when I'm finished.
 
You must log in or register to reply here.
Back
Top