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

[Spark]

Just in case I wasn't clear, custombuild will not touch /etc/ssh/sshd_config. If sshd is already on 22, DA won't touch that.
I was referring to 23 as the default mod_sftp port.. or 26.. doesn't matter.

If the admin would like sshd on some other port, that's totally fine, but up to the admin, for them to do manually themselves. (can be done before the DA install, or whenever they'd like).

However, we can have custombuild look at the /etc/ssh/sshd_config port value... if it's set to something other than 22, then we could set mod_sftp 22.
If 22 is being used by sshd, then it would have to default to something else (eg: 23, or 26, etc..)

John

And in case you dont remember DA admin agrees with me

 

[Spark]

Lets recap what I was saying with some short summaries:

1) Here I was stating there is also ways to configure sftp where there is no plain text auth... Did I say its the way DA should do default... no I was showing there are some other more secure ways of doing ftp, I also at the bottom of that thread was answering your "That is a valuable piece of information" question you had... letting you know that some companies are using cagefs to do so, I should have also stated that some companies are also using Directadmins jail ssh feature.
http://www.directadmin.com/forum/showthread.php?t=43504&p=222334#post222334

2) Here I said it would also be nice to see two factor authentication added in
http://www.directadmin.com/forum/showthread.php?t=43504&p=222335#post222335

3) Here I was recommending that plain text auth be disabled by default for both exim and dovecot and that spam blocker was upgraded to spamblocker 4 for default installs instead of spamblocker 2... I didnt get very detailed because I thought everyone would understand what I was getting at... but obviously I was wrong.
http://www.directadmin.com/forum/showthread.php?t=43504&p=222337#post222337

4) Here I was recommending a way to make sure that any customers who set 777 on their directories, that a little script secures them from exploits being uploaded and ran from those directories
http://www.directadmin.com/forum/showthread.php?t=43504&p=222338#post222338

5) Here I was recommending a security scanner and status page be added to directadmin, to alert admin of suid, 777, shell scripts and more, I also recommeded that others like you add to the list if you have any good scans that would help
http://www.directadmin.com/forum/showthread.php?t=43504&p=222340#post222340

6) Here I was asking that DA further expand on the directories and file permissions, script to make sure that DA installs are secure by default
http://www.directadmin.com/forum/showthread.php?t=43504&p=222341#post222341

7) Here I was saying please dont change the default SSH port as it would be disruptive to those companies who give out ssh access, and yes there are quite a lot of us not just me my friend
http://www.directadmin.com/forum/showthread.php?t=43504&p=222366#post222366

So no where in any of that did I propose something that would be disruptive... I only contributed some ideas... then the rest is you attacking me for doing so.

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

Well I guess this post just sums it up and recaps on every practical recommendation I had for DA to solve this problem that would not be disruptive, and as you can see I was only on one part asking you not to be disruptive... but I now see that DA admin staff had already agreed that port should not be changed from its default so there is no more reason for me to care what you say on the issue of default port.

 

[Spark]

in regards to your concerns about ftp and anonymous access...

I wasnt recommending that DA install my configuration by default... I was simply pointing out since this is in fact a thread about DA security and plain auth over ftp, imap, pop, smtp have been security issues which have been discussed in great depth on various forums that there are ways to configure it so there is no plain auth.

virtual user access still works from proftpd sftp on port 21.... but da will most likely make it so it does both 21 plain and 23 or something else tls auth... just to appease other use cases.


I hope what you take from this, instead of attacking and arguing with someone about their ideas... that next time you ask for clarification if you do not fully understand their intentions. The conversation will be much more productive that way.


What you should have taken from my ftp post was... Oh yeah we can add one more option in the directadmin install procedure that states:

Do you want:

1) SFTP & FTP
2) SFTP
3) FTP

Just like it does when it asks you which version of php do you want installed mod_php suphp, do you want php4 & php5 or just php 5

 

[IT_Architect]

And in case you dont remember DA admin agrees with me.

Please take time to read the conversation you are referencing. I suggested SFTP. Jeff was not comfortable giving everyone who currently has ftp access, full SSH access. I happened to agree with Jeff. Jeff knew that SFTP was part of the SSH2 protocol, that's why he raised the issue. I assured him that ProFTPD does not implement the secure terminal portion of the protocol.

Next, DA decided to evaluate SFTP as a possible solution. Since SFTP is the file transport element of the ssh2 standard, we couldn't have sshd, which implements the full protocol, and ProFTPD, which implements only SFTP & SCP portions, running on the same native port 22. All John was looking for is consensus on a default port for DA. I threw out my idea, which was a high port for SSHD, and I thought initially that John came back with proposing 23 for SSHD, because it was the old Telnet port, and 22 for SFTP, because it is the default in SFTP clients, and because people often hide their SSHD anyway. John then clarified it as he meant the other way around, at which point I stated, I don't care where you put it. There was no contention between John and I on that issue.

Quote Originally Posted by IT_Architect: What practical recommendations do you have for DA to solve this problem that would be the least disruptive to their customer base?

The thread was getting off into different operating systems and everything along the way. That was simply a request to refocus and summarize to give DA something they could use to work with. The summarization in the last two posts brings order and clarity to your recommendations.

When I make a counter point, comment, ask a question, or express an opinion, or even disagree, that is discussion. That does not constitute an attack. If someone makes a statement of opinion or position, it implies the right of others to challenge it, and for the person making the statement to be able to defend it with rationale. Earlier in this thread, John challenged me on my statements concerning FTPS security. I did not consider that an attack, but as the one who made the statement, I did owe him and everyone else an explanation of my rationale so they could judge for themselves if they agree with my rationale. There is no expectation for anyone to know everything or be right every time. I would not lose face if John proved me wrong, I would learn by it, and thank him.

No one has attacked you, nor have I discredited anything you've written. You have attacked me without cause. I stated in the beginning of the thread that I don't care which port they choose for the default, and that wherever they put it, I'd probably go with it on our systems. The only positions that I've maintained in all of this were secure credentials, the ability to maintain the same virtual user security structure for SFTP as we have today for FTP, and as per Jeff's suggestion, maintaining the same control we have today over whether or not to enable secure terminal for users.

Thank you for your suggestions!

 

[Spark]

Please take time to read the conversation you are referencing. I suggested SFTP. Jeff was not comfortable giving everyone who currently has ftp access, full SSH access. I happened to agree with Jeff. Jeff knew that SFTP was part of the SSH2 protocol, that's why he raised the issue. I assured him that ProFTPD does not implement the secure terminal portion of the protocol.

Next, DA decided to evaluate SFTP as a possible solution. Since SFTP is the file transport element of the ssh2 standard, we couldn't have sshd, which implements the full protocol, and ProFTPD, which implements only SFTP & SCP portions, running on the same native port 22. All John was looking for is consensus on a default port for DA. I threw out my idea, which was a high port for SSHD, and I thought initially that John came back with proposing 23 for SSHD, because it was the old Telnet port, and 22 for SFTP, because it is the default in SFTP clients, and because people often hide their SSHD anyway. John then clarified it as he meant the other way around, at which point I stated, I don't care where you put it. There was no contention between John and I on that issue.

Hello I understand where you are coming from and your point, but for clarity, All I was doing in my post was agreeing that the default port should not be changed and offering scenarios of why it shouldnt be changed by default... you immediately started arguing with me about it, a little unclear as to why since you yourself in this reply admitted you dont care where it is located... so maybe your reply should have been to me hey DA admin had already decided to leave ssh on port 22... since I obviously missed that when reading the topic.

The thread was getting off into different operating systems and everything along the way. That was simply a request to refocus and summarize to give DA something they could use to work with. The summarization in the last two posts brings order and clarity to your recommendations.

I agree it was getting off track, but not because of different operating systems or what not... it is important when making decisions like this to take all scenarios/deployments into account. And as such anyone requesting a feature can and should be presented in options during install just like I stated above. Choose 1) SFTP & FTP 2) SFTP 3)FTP... Choose 1) IMAP enable plain text auth ports and TLS auth ports 2) enable only tls auth ports ..... you get the picture.... you sort of jumped to conclusions on what I was requesting... obviously my use case wont match yours or the next guys... it seems to me you got mad that I would even suggest a SFTP only option as if because you need SFTP+FTP thats how it should be and there should'nt be a additonal option for just SFTP... thats how you came off when you started arguing about it

When I make a counter point, comment, ask a question, or express an opinion, or even disagree, that is discussion. That does not constitute an attack. If someone makes a statement of opinion or position, it implies the right of others to challenge it, and for the person making the statement to be able to defend it with rationale. Earlier in this thread, John challenged me on my statements concerning FTPS security. I did not consider that an attack, but as the one who made the statement, I did owe him and everyone else an explanation of my rationale so they could judge for themselves if they agree with my rationale. There is no expectation for anyone to know everything or be right every time. I would not lose face if John proved me wrong, I would learn by it, and thank him.

I agree but maybe you dont understand the power of the words you chose to use, if you read the difference between johns challenges to you and your challenges to me they are very much different

No one has attacked you, nor have I discredited anything you've written. You have attacked me without cause. I stated in the beginning of the thread that I don't care which port they choose for the default, and that wherever they put it, I'd probably go with it on our systems. The only positions that I've maintained in all of this were secure credentials, the ability to maintain the same virtual user security structure for SFTP as we have today for FTP, and as per Jeff's suggestion, maintaining the same control we have today over whether or not to enable secure terminal for users.

Which my proposed solution did allow for all that so I am still confused here.

Referencing back to my post here http://www.directadmin.com/forum/showthread.php?t=43504&p=222390#post222390


the words you chose to use:

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

is a very powerful statement and many people reading it will take it as you discrediting my contributions... What you have wrote implies that my recommendations are disruptive to DA's customer base... It also implies that my recommendations were not practical... Which niether is true if you read my summary post

This statement is an attack, not productive in any way shape or form.

Also reading any of those posts I do not see where I have attacked you... there is only one post there where I wrote I disagree with this... didnt you yourself just say it is okay to disagree?


Just because me or anyone else raises a different idea to make the system secure... doesnt mean they are requesting that it be the default method... its just an idea to add as an option... I might like my system to be SFTP only... you might like your system to be SFTP+FTP... it is all just suggestions that are all controllable via options... You took my post as if I was saying do away with FTP and only use SFTP... but no where did I state that... you actually got quite upset with me about it and me asking for port 22 to NOT be changed from the default.... you were not presenting that as on option were were actually quite clear in your request that it should be changed by default... which is why DA admin staff told you no they will not mess with port 22 if it is use. Again anything requested in this thread should be presented as an option otherwise you could be disruptive to others business models and that is all I was pointing out to you.


And regards to SSH you presented a question for information, you cant argue with me because I told you what others are doing... if you dont want to provide shell access to your users using those methods or cant, then dont, all I was saying is dont change the default because there are those of us that do.


Regardless, like I said many times in my posts, we all have the same goal in mind here, and that is making the default install of Directadmin more secure, presenting options for users who have different use cases, not disrupting the way others do business, and working together to come up with the best solution that meets everyones needs if possible.

 

[IT_Architect]

We agree on all that matters

 

[Spark]

Okay great, now for sanity's sake since this thread got a bit off track I am going to recap one more time so we can move forward, please do the same with what you would like to see in addition to my requests:


1) there is also ways to configure sftp where there is no plain text auth... This should be presented as on option during install 1) SFTP + FTP 2) SFTP 3) FTP ... doing so gives flexibility and allows for different levels of security as well
http://www.directadmin.com/forum/showthread.php?t=43504&p=222334#post222334

2) it would also be nice to see two factor authentication added in, presented as on option in the control panel, not necessarily during install
http://www.directadmin.com/forum/showthread.php?t=43504&p=222335#post222335

3) Plain text auth be disabled for both exim and dovecot and that spam blocker was upgraded to spamblocker 4 for default installs instead of spamblocker 2... This should be an option during install as well: 1) enable plain text authentication and tls auth in exim and dovecot 2) enable only TLS authentication in exim and dovecot (if this option is slected dovecot will only listen on TLS ports 995 and 993 and exim will only allow authentication over 587 and 465)
http://www.directadmin.com/forum/showthread.php?t=43504&p=222337#post222337

4) Here I was recommending a way to make sure that any customers who set 777 on their directories, that a little script secures them from exploits being uploaded and ran from those directories
http://www.directadmin.com/forum/showthread.php?t=43504&p=222338#post222338

5) Here I was recommending a security scanner and status page be added to directadmin, to alert admin of suid, 777, shell scripts and more, I also recommeded that others add to the list if you have any good scans that would help
http://www.directadmin.com/forum/showthread.php?t=43504&p=222340#post222340

6) Here I was asking that DA further expand on the directories and file permissions, script to make sure that DA installs are secure by default... while the thread uses LES as an example those rules being added to directadmins set_permissions.sh script would make this OS independent.
http://www.directadmin.com/forum/showthread.php?t=43504&p=222341#post222341

7) Here I was saying please dont change the default SSH port as it would be disruptive to those companies who give out ssh access, and yes there are quite a lot of us. This should also be presented as an option during install 1) Use default SSH port 2) move ssh to port 1022 3) specifiy my own port
http://www.directadmin.com/forum/showthread.php?t=43504&p=222366#post222366


These "options" could also be added to custombuild options.conf file so one at a later time can change which method they use, also some users do not understand the security implications of some options, or the limitations of some of the security settings... There should be a "DA Security Best Practices" guide written which outlines the benefits and limitations of each option, this way the DA customers are making educated decisions on which options to choose for their business requirements in relation to best security.

 

[nobaloney]

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

Please send me a copy of the relevant changes you've made to SpamBlocker Version 4, for my consideration.

Thanks.

Jeff

 

[nobaloney]

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

Obviously least disruptive is to leave DirectAdmin alone and let admins decide for themselves. Just as obviously, this isn't a good path into the future. That said, both IT_Architect and QuantumNet have been posting the same arguments over and over again and it appears that in the past several days this has scared off other posters. So I strongly suggest that if posts continue to just restate the same things over and over again (whether or not in an accusatory manner), it may be time to close the thread. Points already made.

Jeff

 

[Spark]

Please send me a copy of the relevant changes you've made to SpamBlocker Version 4, for my consideration.

Thanks.

Jeff

#EDIT#1:
local_interfaces = 127.0.0.1 : 12.23.3.43 # Bind mail server to dedicated IP and not servers primary IP
primary_hostname = mx1.exsyshost.com

#EDIT#7:
tls_on_connect_ports = 465
daemon_smtp_ports = 25 : 465 : 587

#EDIT#14:
addresslist whitelist_senders = lsearch;/etc/virtual/whitelist_senders
addresslist blacklist_senders = lsearch;/etc/virtual/blacklist_senders
domainlist blacklist_domains = lsearch;/etc/virtual/blacklist_domains
domainlist whitelist_domains = lsearch;/etc/virtual/whitelist_domains
domainlist local_domains = lsearch;/etc/virtual/domains
domainlist relay_domains = lsearch;/etc/virtual/domains : localhost
domainlist use_rbl_domains = lsearch;/etc/virtual/use_rbl_domains
domainlist skip_rbl_domains = lsearch;/etc/virtual/skip_rbl_domains
hostlist auth_relay_hosts = *
hostlist bad_sender_hosts = lsearch;/etc/virtual/bad_sender_hosts
hostlist bad_sender_hosts_ip = /etc/virtual/bad_sender_hosts_ip
hostlist whitelist_hosts = lsearch;/etc/virtual/whitelist_hosts
hostlist whitelist_hosts_ip = /etc/virtual/whitelist_hosts_ip

DKIM_DOMAIN = ${lc:${domain:$h_from:}}
DKIM_FILE = /etc/virtual/${lc:${domain:$h_from:}}/private.key
DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}}

#EDIT#23:
tls_certificate = /etc/.ssl/server.pem
tls_privatekey = /etc/.ssl/server.key
tls_require_ciphers = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
tls_advertise_hosts = *
# If you want to advertise the availability of AUTH only when the connection is encrypted using TLS, you can make use of the fact that the value of this option is expanded, with a setting like this:
auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}


#EDIT#26:
acl_check_recipient:
  # block certain well-known exploits, Deny for local domains if
  # local parts begin with a dot or contain @ % ! / |
  deny  domains       = +local_domains
        local_parts   = ^[.] : ^.*[@%!/|]
  # restrict port 587 to authenticated users only
  # see also daemon_smtp_ports above
  accept  hosts = +auth_relay_hosts
          condition = ${if eq {$interface_port}{587} {yes}{no}}
          endpass
          message = relay not permitted, authentication required
          authenticated = *
  # restrict port 465 to authenticated users only
  # see also daemon_smtp_ports above
  accept  hosts = +auth_relay_hosts
          condition = ${if eq {$interface_port}{465} {yes}{no}}
          endpass
          message = relay not permitted, authentication required
          authenticated = *


#COMMENT#61:
remote_smtp:
  driver = smtp
  interface = 12.23.3.43 #makes mail to be sent out on IP that is not the servers main IP
  dkim_domain = DKIM_DOMAIN
  dkim_selector = x
  dkim_private_key = DKIM_PRIVATE_KEY
  dkim_canon = relaxed
  dkim_strict = 0

 

[Spark]

Obviously least disruptive is to leave DirectAdmin alone and let admins decide for themselves. Just as obviously, this isn't a good path into the future. That said, both IT_Architect and QuantumNet have been posting the same arguments over and over again and it appears that in the past several days this has scared off other posters. So I strongly suggest that if posts continue to just restate the same things over and over again (whether or not in an accusatory manner), it may be time to close the thread. Points already made.

Jeff

Jeff could you please remove post #34 - #46 this will clean things up again and keep the thread productive... there are some good ideas here... would really like to see two factor authentication added in to prevent stuff like happened to WHMCS

 

[Spark]

not so much a security measure but more of anti spam measure... in the exim config I posted above... if the dkim code I provided was added into spamblocker4 and then the control panel generated the key and saved it in the appropriate /etc/virtual folder for the site, when sites were created... and maybe a tool for existing sites as well... this would definitely be a plus

right now we manually generate the keys when customers ask... we already automatically create their dkim txt DNS entry through the custom templates


then again we could write a post create hook as well to do this, now that I think about it... but it would be beneficial to others to have this as part of the default setup.

 

[nobaloney]

Please tell me more about DKIM in your code. If it requires any special compilation or setting up of keys I'm not sure I want it in the default until we can get DirectAdmin coding done.

Thanks.

Jeff

 

[Spark]

Basically in edit #14 we set up a couple more config lines:

DKIM_DOMAIN = ${lc:${domain:$h_from:}}
DKIM_FILE = /etc/virtual/${lc:${domain:$h_from:}}/private.key
DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}}

what this does is look for the private.key file inside the domains virtual folder before sending out an email


then comment #61 signs the outgoing email with the domains key if it exists:
dkim_domain = DKIM_DOMAIN
dkim_selector = x
dkim_private_key = DKIM_PRIVATE_KEY
dkim_canon = relaxed
dkim_strict = 0


it would in part either need DA to generate the openssl private key when a domain gets created.... otherwise I can write a custom post_create script to be placed inside /usr/local/directadmin/scripts/custom


this would accomplish the same thing until DA integrated it into the CP.

then on your website where you have the special instructions you could include a paragraph that stated to enable dkim authentication copy this script to your custom scripts folder. But it would be better if this was already part of DA once DA defaults to using spamblocker4 people might miss that they needed to do that step.

 

[DirectAdmin Support]

Hello,

I'm not sure if you were aware, but DA already has an internal implementation of DKIM as of 1.38.0, which is off by default:
http://www.directadmin.com/features.php?id=1189

is fairly close to yours, but with the dkim=1 option in the directadmin.conf, DA will create everything for you.

John

 

[Spark]

Thanks John

Well there you go Jeff they have already created the script which creates the dns entries and private key file, so adding it to spamblocker4 should be cake...

I had done my implementation a couple years back when that did not exist.. I see they state it as beta... I will test it out on one of our customer servers and let you know how it goes

 

[nobaloney]

Yes, please post again when you know it works with your changes to SpamBlocker Version 4, so I can make the update.

Jeff