Change HTTPS for a single site/vhost?

This question has been asked in different ways over time but I haven't found a solid solution. And I'm really sorry if I asked this myself but can't find the previous thread.

Is there an elegant way to change the HTTPS port for a single site/vhost? That is, for Apache, to change <VirtualHost *:443> to *:00000?

Reason: I have a server with many WordPress sites that I want to lock down from all remote access. So ports 80/443 are closed to public access. But I want to invite some people to one of the sites.

The ideal situation would be for the Site management page to have a Port field for an integer value that's saved into the .conf directive. Aside from maybe a lack of requests, is there a reason why this isn't already a feature?

For now, the only thing I can think of with my current understanding of ISPConfig, is to copy the VirtualHost node and paste into the Apache Directives so that it looks like a different site. OR, just edit the .conf file, and (citing a recent thread on this topic) use incron or a similar process to ensure the file stays the way I want it. [[ I am doing that now, set *:00000 and then add "Listen 00000" to ports.conf, then reload apache2. ]]

Other suggestions? Thanks!

 

There is none in my knowledge. For now, custom vhost is the only way to do it with chattr +i command to protect it from changes.

 

I revisited this and I think that you can simply copy current vhost and name a new one without following ISPConfig covention for vhost filename with the desired port(s). However, this is just a mere suggestion how to go about the said problem and that said, I am not using apache and never tested this as well, so I am sorry if this idea misleads in any ways.

 

even if you change the ports, it's only protection by obscurity. all your open ports ARE going to get scanned, and when someone knows it's open, if they access that port in a browser they're straight into your site anyway.

surely a simpler option is leave it on the standard ports and use a wordpress plugin to password protect the entire site, or use the protected folders feature in ispconfig to protect the docroot, which will extend it's protection to all subfolders.
fail2ban or wordfence etc will protect you from brute force attempts.
the protected folders option will also allow you to create different logins/password per user.

 

Sincere thanks for your comments and efforts - truly, thanks.

Response 1: As noted above:

So if I open 443 then all sites are open and I will need to close down the other sites as you've noted with other tools. But the other sites are already locked down. I just want to open one by making changes for one. I'd prefer not to mess all of the rest just so I can open one.

Response 2: Sometimes "I just want" is not the right thing to do. Perhaps the proper way to approach this is to go ahead and open 80/443 as normal, and then lock down each site that I don't want visible to the public.

I've been wanting to avoid a scenario where I have the standard ports open, setup sites, and then need to shift focus to each application to secure it or deal with hacker damage. As I think about it, from the ISPConfig perspective, the first challenge should be to secure the site, so then it shouldn't matter what's happening at the application level. With proper chrooting and permissions, damage in any one site shouldn't propagate to others.

So, I'll accept that ISPConfig doesn't yet allow for custom per-site ports, and probably for good reasons that I should learn. Unless there is another suggestion based on this, I'll thank you guys again, and close this request.

 

I always create each site with its own vhost, in muti domain single database case, like wpmu, so with this preference it is possible to have one of its sites to have a different, unique, customized vhost file.

I thought this is also what you were doing but re-reading your posts, now I think may be you created wp multiple sites with single vhost i.e. without their own vhost file, so my earlier suggestion will not be of any use to you.

 

I am doing that : For foo.tld there is a Website with a .conf. Also, for aaa.foo.tld and bbb.foo.tld there are two subdomain vhosts, with their own configs. So it will work to change the port in a .conf file and then set it to Immutable.

Sidebar: You just made me realize that I have not been making ideal choices for some site structures. For every primary domain.tld there is a "Website". But for subdomains running different applications, I have only been creating subdomain vhosts. I have not used the "subdomain for website" feature at all yet. For most of what I've created here so far, it's desirable to have a single web00 user for all sites under domain.tld. But I do have some subdomains that should be isolated - these should eventually be moved to their own "Website". Thanks for that.

In case I'm missing something, why aren't ports used more as a way of sectioning off sites into categories like development, beta, intranet, extranet, and production? Is this not "a thing" outside of ISPConfig? If it is, then why hasn't ISPConfig accommodated the concept? Wouldn't this be a simple field in the template along with a Port field in the maintenance screen? I'm guessing it's a simple lack of priority given the audience for this software, but I'd like to know if this is simply a bad practice. Thanks for your indulgence.

@nhybgtvfr said

I totally get that, and "security by obscurity" doesn't work. The intent here is only to keep sites/applications that are in-development from being hit by common requests. I've just been trying to put off the onslaught of hackers, where having the one port 443 open subjects all sites to immediate scanning. Meh, I can't avoid the inevitable forever. So...

I'll leave this open for a while for better ideas but the plan so far is to open the server to 80/443, ensure security is handling it, and lock down applications at the application level and .htaccess / .htpasswd.