Time for a re-think of DA's install security defaults

[IT_Architect]

First of all, I don't care what port you pick for a default. I'll stick with it just to make the support experience go easier. Perhaps the thing to do is see what the other CPs are using, and if there is a defacto standard out there already.

From IT_Architect's comment:With FTPS, we know that the control channel (username/password) is secure.. However, I'm curious about your comment that the data channel not being secure. From a few quick googles, I wasn't able to find anything that says the data channel cannot be secured, only that it's optionally secured. Are you able to elaborate on this for us?

Usually there is no easier way to secure a protocol than with TLS. However, there are two problems, the FTP protocol, and FTPS has so many standards, there are none. FTP without encryption has always had firewall and NAT problems. Firewalls had to build in smarts to monitor the conversation to know what ports to open. Once your run a pipe through the firewall, it can't monitor the conversation. My Dreamweaver sends the credentials, in the clear and then after things are set up, goes to secure. The reason they do that is because of the way firewalls interact with FTP, is they snoop the conversation, and determine from that which ports to open for the dynamic ports. If I'm sending credentials in the clear, it's nothing but an "exercise" because anybody can read the credentials, and log into the site I'm sending to. Some servers take a dim view of sending credentials in the clear, so I cannot connect with my Dreaweaver. Instead, what they do is permanently open a port range for ftp. Then there is triple c. What that does is secure authentication, and then puts the control channel in the clear so the firewall can pick up on what is going on, and open the ports necessary. The problem is not many clients support it, and mod_tils surely doesn't, so that throws out ProFTPD. Some servers try to adapt starting at the most secure and working their way down. FTPS requires multiple clients and some good fortune to make it work. If you connect easily, chances are it wasn't securely. Due to these complexities and much easier to secure protocols being available, I see FTP remaining for efficient unauthenticated access, and FTPS never getting much traction. With SSH/SFTP/SCP, it only works one way, no firewall dances, and any client you choose will work. However, I'm open to anything that doesn't give away credentials.

On a side-note, I've already got sftp working with proftpd on a test box. It does need a few weird proftpd.conf changes (setting "Port 0", adding Port 21 into a 0.0.0.0 VH) to make it bind to all IPs, but nothing drastic.
Worst case, I'll just write up a how-to guide.

Awesome! Tonight, my Dad wanted to take all of us kids out to eat. I had a server go down while we were at the restaurant. Zabbix sent a text message to my phone, and I fixed it from the restaurant. Because the workplace has been redefined, the only responsible thing we can do is enforce secure communication. Why bother locking the doors with mod_ruid2 if we're going to allow our hosting customers and their employees to give away the keys to strangers? LOL! I'd like to force secure E-mail and SFTP at the same time to get this behind me.

If you have a HOW TO that works automatically when they add new FTP users, I'd love to try it. Anything that requires credentials needs to be encrypted.

Thanks!

 

[IT_Architect]

...We already offer shell access to all clients (its "safe" with SAG and suPHP etc), and is using default port 22. So clients use real SFTP on port 22...If DirectAdmin could implement option to enable SSH for all ftp only accounts (not only on main default user account), that would be great! Then we could offer clients real SSH/SFTP on all the accounts they create.

I believe there would be few willing to give users, let alone 3rd parties, access to all of the OS commands on a shared hosting server. That's quite a risk expansion, with much to think about.

Any time you see SFTP offered, the implication is it doesn't include terminal capabilities. There is nothing fake about that, it's an industry expectation, and why ProFTP added it.

 

[ditto]

@IT_Architect I don't agree with you. Also many big shared hosting companies give full ssh access on shared hosting servers, one example is DreamHost. I will not discuss this any further, and will not answer any replies regarding this. I have my opinion, and have made my choice. We do not have to agree, that is fine with me.

 

[IT_Architect]

...Also many big shared hosting companies give full ssh access on shared hosting servers, one example is DreamHost.

That's a valuable piece of information. I and everyone else WANT your hat in the ring to hammer these ideas out. I'm open to anything that's safe, doesn't compromise user's credentials, and that works for DA and their customers.

 

[Arieh]

That's a valuable piece of information. I and everyone else WANT your hat in the ring to hammer these ideas out. I'm open to anything that's safe, doesn't compromise user's credentials, and that works for DA and their customers.

Look into cloudlinux, their cagefs is designed for this. I'm testing it for a little while with DA and it works great. http://www.cloudlinux.com/docs/cagefs/index.php

 

[Spark]

We use sftp in proftpd... but we configured it so that it no longer serves standard ftp... and it remains on port 21 as anything else just confuses non technical people... we then tell them to use sftp aware ftp clients in our welcome email such as filezilla or winscp

proftpd.conf... unrelated stuff stripped:

ServerType standalone
Port 21

# extended log commented out because it breaks sftp
#ExtendedLog /var/log/proftpd/74.86.16.186.bytes WRITE,READ userlog

#SFTPLog /var/log/sftp.log
#TraceLog /var/log/sftp-trace.log
#Trace DEFAULT:10 sftp:20 ssh2:10 scp:20

SFTPEngine On
SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key

# Enable compression
SFTPCompression delayed

# Allow the same number of authentication attempts as OpenSSH.
#
# It is recommended that you explicitly configure MaxLoginAttempts
# for your SSH2/SFTP instance to be higher than the normal
# MaxLoginAttempts value for FTP, as there are more ways to authenticate
# using SSH2.
MaxLoginAttempts 6

<Global>

SFTPEngine On
SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key
SFTPCiphers blowfish-cbc 3des-cbc

SFTPLog /var/log/sftp.log

# Enable compression
SFTPCompression delayed

# Allow the same number of authentication attempts as OpenSSH.
#
# It is recommended that you explicitly configure MaxLoginAttempts
# for your SSH2/SFTP instance to be higher than the normal
# MaxLoginAttempts value for FTP, as there are more ways to authenticate
# using SSH2.
MaxLoginAttempts 6

# General sftp client fixes from the mod_sftp forum
SFTPClientMatch ".*WS_FTP.*" channelWindowSize 1GB #WS_FTP initial window size
SFTPClientMatch ".*ClientSftp" sftpProtocolVersion 3 #CuteFTPPro8
SFTPClientMatch ".*WinSCP.*" sftpProtocolVersion 3 #upload/download fix for WinSCP
#
# SecureBlackbox (SSH-2.0-SecureBlackbox.7)
# http://www.eldos.com/sbb/download-release.php
SFTPClientMatch ".*SecureBlackbox.*" sftpProtocolVersion 3
#
# GoAnywhere (SSH-2.0-1.0)
# http://www.goanywheremft.com/products
SFTPClientMatch "1.0" sftpProtocolVersion 3 channelWindowSize 1GB
#
# JaSFtp (SSH-2.0-J2SSH_Maverick_1.2.10_Sterling Commerce)
# http://www.hiteksoftware.com/jasf/
SFTPClientMatch ".*J2SSH_Maverick.*" channelWindowSize 1GB
#
# Robo-FTP (SSH-2.0-WeOnlyDo)
# http://www.robo-ftp.com/
SFTPClientMatch ".*WeOnlyDo.*" sftpProtocolVersion 3 channelWindowSize 1GB
#
# Network Automation (SSH-2.0-EldoS.SSHBlackbox.3)
# http://www.networkautomation.com/
SFTPClientMatch ".*EldoS.SSHBlackbox.3.*" sftpProtocolVersion 3 channelWindowSize 1GB
#
# /n Software BizTalk SFTP Receive (SSH-2.0-IP*Works! SSH Client v8.0)
# http://www.nsoftware.com/products/biztalk/adapters/sftp.aspx
SFTPClientMatch ".*IP.Works.*" channelWindowSize 1GB

#PassivePorts 35000 35999

basically this sets the default ftp listener as well as the vhost listeners to all be sftp... also the extended log in each vhost config file needs to be commented out as well or removed which can be done via directadmin custom template


SSH lives on port 22... because we give out shell access while using cagefs to keep the system secure

 

[Spark]

would also like to see two factor authentication added in for a minimum of admin and reseller accounts but could also be made vailable to end users...

http://www.duosecurity.com/

Free for first 10 users... so perfect for admin accounts... and it is dead simple anyone can do it right from their phone
http://www.duosecurity.com/pricing

 

[Spark]

we also give out ssh access using cloudlinux cagefs

 

[Spark]

we also use spamblocker 4 and have disabled plain text auth and only allow 587 and 465 for legacy microsoft clients

same for dovecot only tls auth it does not even listen on non ssl ports

 

[Spark]

Not every host likes using php_fcgi or suphp or the likes... lets not argue about what is more secure, because it can go back and fourth... some prefer to secure their systems in different ways then allowing websites to be easily defaced and backdoors easily inserted because of the whole site is one big 777 that suphp and the others do.

What about an automated cron that runs and drops a .htaccess file into any 777 directories for mod_php

for dir in `/usr/bin/find /home/*/domains/ -type d \( -perm -2 -o -perm -20 \)`
do
if [ ! -f ${dir}/.htaccess ]
then
/bin/cp -a /usr/local/sbin/secure.htaccess ${dir}/.htaccess

user=`echo ${dir} | awk '{split($0,a,"/"); print a[3]}'`
/bin/chown ${user}:${user} ${dir}/.htaccess
fi
done

for dir in `/usr/bin/find /home/*/domains/ -type d -user apache`
do
if [ ! -f ${dir}/.htaccess ]
then
/bin/cp -a /usr/local/sbin/secure.htaccess ${dir}/.htaccess

user=`echo ${dir} | awk '{split($0,a,"/"); print a[3]}'`
/bin/chown ${user}:${user} ${dir}/.htaccess
fi
done

exit 1

<Files ~ "^.*\.(php|cgi|pl|php3|php4|php5|php6|phtml|shtml|sh)">
Order allow,deny
Deny from all
</Files>

 

[Spark]

What about a security scanner page in DA that keeps admins notified through the ticket system when it locates suspicious files:

#!/bin/bash

mycompname=$(hostname)
mydir=/root/$mycompname
myoutput=$mydir/secoutput.txt
mkdir -p $mydir

sl()
{
SECTION=$1
echo >> $myoutput
echo **********$SECTION********** >> $myoutput
echo >> $myoutput
}

echo ^^^^^^^^^^ START OF OUTPUT ^^^^^^^^^^ > $myoutput

echo -n Is this a Red Hat \(r\) or a Debian based system \(d\)?
read REPLY

case "$REPLY" in
'r')
yum list updates > $mydir/patchcheck.txt
sl "Service Runlevels";chkconfig --list >> $myoutput
sl "Auth Messages";cat /var/log/secure|grep failure >> $myoutput
;;
'd')
apt-get update
apt-get -qs upgrade > $mydir/patchcheck.txt
sl "Startup Services";ls -l /etc/rc2.d >> $myoutput
sl "Auth Messages";cat /var/log/auth.log|grep failure >> $myoutput
;;
esac

sl "lastb Results";lastb >> $myoutput
sl "inetd check"; file -f /etc/inetd.conf && \
echo "Are you using inetd? You should be using xinetd instead." \
>> $myoutput
sl "xinetd Services";ls -l /etc/xinetd.d >> $myoutput
sl "hosts.allow";cat /etc/hosts.allow |grep -v "#" >> $myoutput
sl "hosts.deny";cat /etc/hosts.deny |grep -v "#" >> $myoutput
sl "iptables output";iptables --list >> $myoutput
sl "SUID Files";find / -perm -4000 -print >> $myoutput
sl "SGID Folders";find / -perm -2000 -print >> $myoutput
sl "777 Folders";find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print >> $myoutput
sl "No Owner Files";find / -xdev \( -nouser -o -nogroup \) -print >> $myoutput
sl "Possible shell scripts";find /var/www/html/ -name \*.php -type f -print0 | xargs -0 grep -RPn "(c99|r57|passthru|shell_exec|system|base64_decode|fopen|fclose|eval)" >> $myoutput
sl "SUDoers";cat /etc/sudoers|grep "="|grep -v "#" >> $myoutput

echo -n "Do you want to capture Password Files"
echo -n " for an offline Password Check (y or n?)"?
read REPLY2

if [ $REPLY2 = "y" ]; then
cp /etc/passwd /tmp/seccheck/$mycompname
cp /etc/shadow /tmp/seccheck/$mycompname
echo Your Password and Shadow folders have been copied to
/tmp/secheck/$mycompname
else exit
fi

echo vvvvvvvvvv END OF OUTPUT vvvvvvvvvv >> $myoutput

More checks can be added to this... I found the script online and added a few more useful scans... lets see what others you guys have up your sleeves.


P.S. it probably needs a management panel where we can mark files as not suspicious, that way we dont keep getting emails about files which have been deemed safe.

Also the ability to have an exclude list for some of the checks for instance you would not want to keep scanning for 777 directories in the /home partition

 

[Spark]

maybe some admins dont know about scripts like these:
http://www.rfxn.com/projects/linux-environment-security/

maybe directadmin can add some of these to its set permissions script... like the following rules:
-sb | --secure-bin Set root only execution of critical binaries
-sp | --secure-path Set root only traversal of critical paths
-sd | --secure-devel Set access to devel utils for group deva & root


but make each role optional maybe through the control panel?

 

[Spark]

The default port for most SFTP clients is 22, so I believe it makes the most sense to move sshd. My reasoning is that it is common practice already to move sshd off the standard SSH port, and individuals given shell access are technical users. 220 and 2200 are taken, but 22000 is not, and it's outside of the default FTP ephemeral range

I do not agree with this... some say it is better to move SSH off a default port... I disagree... any scanning tool will detect SSH regardless of what port it is on... we give our users SSH access all of them not just technical...

We dont want to support telling everyone change your port before hitting connect in putty ssh client... so we leave ssh on port 22, sftp on port 21... we then run LFD login failure daemon which handles any fo the bruteforce attacks at the firewall level via CSF iptables firewall script

do not forget that ssh has a sftp subsystem so if users are having issues on SFTP they can connect to port 22 via the main ftp account while waiting on support to fix the issue. And yes SFTP does break.. updates to proftpd more than a couple times have made it so we needed users to connect to ssh port 22 until we could roll back the upgrade and wait until proftpd released their next update before proceeding.

 

[IT_Architect]

We use...

It's fun to learn listening to all of the different ways people deploy. We actually have our business on the servers, and the web hosting customers are simply people who help pay for them. We back up across to each other and since they are VMs, if there is a problem, we can just start the VM on the box it backs up to. The customers get that benefit also.

We use sftp in proftpd... but we configured it so that it no longer serves standard ftp... and it remains on port 21 as anything else just confuses non technical people... we then tell them to use sftp aware ftp clients in our welcome email such as filezilla or winscp

I'm glad DA plans to implement in a flexible way. LOL! For the general hosting customers, there is a need for Public FTP. For Private FTP areas, there needs to be a system like they have now where you can set the root for the users and web developers or they would be able to access each others areas. E.G. Honda puts their files in the Honda directory, and GE puts their files in the GE directory, etc. The customer's engineers have access one directory below so they can get at files from each of their customers, but they can't get to the web site files. These are located below where the web developers work, so they can't get to those files, etc. One of the things that tipped the balance for us to go DA is DA was the only one at the time we could do that with. cPanel moved to it afterwards based on a discussion I started on WebHostingTalk in which the cPanel principal participated.

we also give out ssh access using cloudlinux cagefs

We moved away from Linux some time ago. We probably won't do the Jails thing because performance is so critical for us. At 3 AM the servers are still doing 15-20 pages a second, and we do backups and maintenance then, but from morning to evening they do 60 to 140 pages a second, and they are tough pages with 1/4 of the content coming from elsewhere on the web, and graphics being created on the fly. If we were anywhere near normal, something like that could make sense for us.

...and only allow 587...for legacy microsoft clients

That doesn't make sense to me. 25 is for SMTP between servers. 587 is mail submission, and the port mail clients should be using, TLS or otherwise. ISPs block 25 to foreign servers for dynamic IP customers so spammers on their networks don't get their address blocks blacklisted. They only port 25 traffic they grant dynamic IP customers is on the ISP's network.

I do not agree with this... some say it is better to move SSH off a default port... I disagree... any scanning tool will detect SSH regardless of what port it is on...

I don't move it, but I don't know if that assumption is correct. For instance, it's a lot easier to see if ports are at their defaults than scan / response, PF blacklists scanners, and if people are paranoid enough to move the port, then perhaps I'd be better moving on to an easier target. LOL! I think there are quite a few people that have said their brute force attacks are way down by simply moving it. I may try it just to see if they are correct.

... we give our users SSH access all of them not just technical...

Just thinking about DAs base, I'd guess not many are on CageFS, but I can see the advantages. I'd be happy at the point with an implementation of mod_ruid2 from DA.

 

[Spark]

I'm glad DA plans to implement in a flexible way. LOL! For the general hosting customers, there is a need for Public FTP. For Private FTP areas, there needs to be a system like they have now where you can set the root for the users and web developers or they would be able to access each others areas. E.G. Honda puts their files in the Honda directory, and GE puts their files in the GE directory, etc. The customer's engineers have access one directory below so they can get at files from each of their customers, but they can't get to the web site files. These are located below where the web developers work, so they can't get to those files, etc. One of the things that tipped the balance for us to go DA is DA was the only one at the time we could do that with. cPanel moved to it afterwards based on a discussion I started on WebHostingTalk in which the cPanel principal participated.

Yes indeed if they do... reason I wrote that is you were promoting that default ports be changed and no that would significantly hamper shared hosting market and create un-necassary support tickets. the shared hosting market is what DA was designed for... you are an unusual case

We moved away from Linux some time ago. We probably won't do the Jails thing because performance is so critical for us. At 3 AM the servers are still doing 15-20 pages a second, and we do backups and maintenance then, but from morning to evening they do 60 to 140 pages a second, and they are tough pages with 1/4 of the content coming from elsewhere on the web, and graphics being created on the fly. If we were anywhere near normal, something like that could make sense for us.

You are making some serious assumptions here... benchmark cagefs before drawing such conclusions... it doesnt have a performance impact... in fact while you dont have to cage the web you can cage just the ssh logins... this way ssh access doesnt impose a security risk.

That doesn't make sense to me. 25 is for SMTP between servers. 587 is mail submission, and the port mail clients should be using, TLS or otherwise. ISPs block 25 to foreign servers for dynamic IP customers so spammers on their networks don't get their address blocks blacklisted. They only port 25 traffic they grant dynamic IP customers is on the ISP's network.

Umm you are mis-understanding what I was saying... you requested that we use secure ports as default on directadmin... I was agreeing with you... we only allow auth over 587 tls, and auth over 465 for legacy microsoft clients such as older versions of outlook... We do not allow clients to authenticate over port 25, niether do we allow them to authenticate to dovecot over not tls ports... we configured dovecot to only listen on tls ports.

I don't move it, but I don't know if that assumption is correct. For instance, it's a lot easier to see if ports are at their defaults than scan / response, PF blacklists scanners, and if people are paranoid enough to move the port, then perhaps I'd be better moving on to an easier target. LOL! I think there are quite a few people that have said their brute force attacks are way down by simply moving it. I may try it just to see if they are correct.

It is not an assumption I actually know a lot about scanners have personally used hundreds of them to perform security audits, changing the default port would only cut down on scanners which are specifically set to identify port 22... when you run a scan you can set it to scan known defaults which is just a handful of ports or you can perform a complete port discovery scan which then the scanner runs finger printing to identify the service listening on the open port.

Systems such as CSF defend against this when they detect a port scan... but the same can be said about LFD which detects brute force attacks on many things ftp, SSH, IMAP, SMTP and so on.

SO since we have tools to defend against either attack then changing default ports just increases our support workload of why is your system different from the rest of the world.

Just thinking about DAs base, I'd guess not many are on CageFS, but I can see the advantages. I'd be happy at the point with an implementation of mod_ruid2 from DA.

No they are not, but many use other forms of jails... cagefs just happens to be the most secure of them all... but again this was in response to me agreeing with other posts in this thread where others have stated that many hosting companies do give out ssh access and we happen to be one of them...

mod_ruid2 has security issues, I dont know from personal experience but I guess it states it in their own documentation and is frowned upon by the creator of cloudlinux:
http://cloudlinux.com/solutions/forum/messages/forum18/topic343/message1636/#message1636
http://www.directadmin.com/forum/showthread.php?t=37467&page=3

we do need to make Directadmin secure by default but not by making it more locked down to cater to someone such as yourself who has a very unique use case, which is the only reason I chimed in here and show how we deploy... and to add a few you had not offered up to the table.

 

[Spark]

to add in regards to your comment about ftp... I do not believe sftp changes anything in regards to what you require in your deployment... you will still have that flexibility... it is the same ftp server just over a different protocol... but then again after I think about it, it might prevent browser access of ftp://server

but in all reality our goal is providing a secure shared hosting environment and if doing so means giving up a couple ftp features in order to avoid MIM attacks then so be it... but plain text auth is a thing of the past on our servers

 

[Spark]

Originally Posted by ditto
...Also many big shared hosting companies give full ssh access on shared hosting servers, one example is DreamHost.

That's a valuable piece of information. I and everyone else WANT your hat in the ring to hammer these ideas out. I'm open to anything that's safe, doesn't compromise user's credentials, and that works for DA and their customers.

Just wanted to remind you of your statement in regard to giving out ssh access, so when users offer up solutions or ideas you are not too quick to jump on them when they give you that "Valuable piece of information" on how it is accomplished


We all have the same goals here, a more secure default install of directadmin, but lets try and work together with ideas, and while doing so make sure those ideas will only add functionality not disrupt the way others do business... like changing default ports.

There is many hosts that do not have the level of knowledge about securing their systems that you or I have, so my hats off to you for starting this thread... I just want to help contribute with things you might have not thought of.

 

[Spark]

I see that you wrote, you moved away from linux so I am taking a quick guess that it was to BSD... I used to be a BSD admin long before I was a linux admin... while you cannot use scripts like CSF and LFD there are similar scripts for handling brute force attacks and scans.

http://home.earthlink.net/~valiantsoul/pf.html
http://www.cyberciti.biz/faq/freebsd-openbsd-pf-stop-ftp-bruteforce-attacks/

http://www.fail2ban.org/wiki/index.php/Main_Page

http://sourceforge.net/projects/sentrytools/


setting these up you wont have to worry about default port changes and security scans

 

[IT_Architect]

while you cannot use scripts like CSF and LFD there are similar scripts for handling brute force attacks and scans.

This is all in PF, which is part of BSD.

reason I wrote that is you were promoting that default ports be changed and no that would significantly hamper shared hosting market and create un-necassary support tickets. the shared hosting market is what DA was designed for... you are an unusual case... we do need to make Directadmin secure by default but not by making it more locked down to cater to someone such as yourself who has a very unique use case... like changing default ports... We use sftp in proftpd... we configured it so that it no longer serves standard ftp... and it remains on port 21 as anything else just confuses non technical people... we then tell them to use sftp aware ftp clients in our welcome email such as filezilla or winscp

In an attempt to refocus on the objective:
1. DA's customers will not move in the next 3 months from from whatever they are on today to CloudLinux and CageFS
2. sshd works at the user level, not virtual user level.
3. DA's customers currently have the ability to allow or deny secure terminal access to users.
4. There is a very widespread need for anonymous FTP. Companies everywhere use it to distribute everything from software to advertising brochures to MSDS Sheets to Supplier Standards. Nixing this would be a huge disruption to the way others do business.
5. A secure FTP site structured and secured by vendor/customer is a common requirement. It's how anyone involved at any level of manufacturing and engineering exchange information. This introduces the requirement for virtual users.
6. At this point we have two SSH daemons, one with the full suite allowing secure terminal operations, and another with the only SFTP and SCP. If we have two daemons using the SSH protocol, one or the other needs to be on a non-standard port.
7. Everyone is in agreement that the current situation of giving away credentials at the hotel, restaurant, and airport represents grave threat to systems, reputations, and more.

What practical recommendations do you have for DA to solve this problem that would be the least disruptive to their customer base?

Thanks!

 

[Spark]

This is all in PF, which is part of BSD.

Like I said it has been a while since I was a BSD admin so a lot has changed, well since you clearly know these exist then there is not a need to change the default SSH port

In an attempt to refocus on the objective:
1. DA's customers will not move in the next 3 months from from whatever they are on today to CloudLinux and CageFS

No one was asking them to you asked for that valuable piece of information on how it was done, I provided it to you... you attacked me like I was saying everyone needs to switch to this... I never said that, I only was letting you know that there are secure ways of doing so... There are also many hosts who use directadmin that use directadmins built in chroot on the ssh shell to provide ssh access, but it is by no means as secure.

My point was yes its being done and in practice at main hosting companies. SO I dont know why you are argueing with me about this and making assumptions about stuff I never said.

2. sshd works at the user level, not virtual user level.

Yes I am aware of this... kind of cunfused why its relevant as no where did I indicate otherwise

3. DA's customers currently have the ability to allow or deny secure terminal access to users.

Yes you are right... again confused at what this point is about

4. There is a very widespread need for anonymous FTP. Companies everywhere use it to distribute everything from software to advertising brochures to MSDS Sheets to Supplier Standards. Nixing this would be a huge disruption to the way others do business.

I would have to double check on this but please explain why using proftpd under the sftp module would prevent this? Why would it suddenly stop the anonymous virtual user account?

5. A secure FTP site structured and secured by vendor/customer is a common requirement. It's how anyone involved at any level of manufacturing and engineering exchange information. This introduces the requirement for virtual users.

Yeah no kidding... I never suggested anything that would change this

6. At this point we have two SSH daemons, one with the full suite allowing secure terminal operations, and another with the only SFTP and SCP. If we have two daemons using the SSH protocol, one or the other needs to be on a non-standard port.

proftpd is not an ssh daemon.. SSHD is an SSH daemon... leave the ssh protocol on its port... period. just because you are changing proftpd through a mod_sftp to use "some" of the ssh technologies doesnt make it an SSH daemon... it should still remain on port 21 to avoid customer confusion and an increase in trouble ticket support.

7. Everyone is in agreement that the current situation of giving away credentials at the hotel, restaurant, and airport represents grave threat to systems, reputations, and more.

Not quite sure what your point is here, or how it applies to anything I have stated

What practical recommendations do you have for DA to solve this problem that would be the least disruptive to their customer base?

Thanks!

Wow dude, you really have some nerve... I am done helping in this thread, I stated in my last post that we all have the same goals, which is a more secure default install of directadmin, so we should work together... and that what I posted was to only point out that there are plenty of directadmin based businesses that would negatively effect if some of your ideas were put into place. I agreed with most of yours if you read up... It was not to argue with you, it was only to show you the light, that running around changing default ports on default install is going to cause some confusion for the hosting industry.

But yet you attack everything that I put on the table that is being used elsewhere and guess what I am not the only one

Then you try and discredit anything I have said in any of my posts with a child like statement of What practicle recommendations do you have that wont disrupt to their customer base?

Sorry but read back I have posted tons of stuff that would not disrupt the customer base... What I was asking is that you dont request changes that will disrupt customer base... you are the one asking for disruptive changes not me.


ANyways again I came here to work with you quit attacking me.... you obviously cannot take the fact that anyone else would like to input to your little thread, exchange ideas, or help shed light on your questions... Because that is all I did then you freaked out.